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1.0  Introduction 

Systematic,  architecture-based  reuse  is  a  key  theme  of  the  DoD  Reuse  Vision  and  Strategy 
[DoD92]  and  a  major  focus  of  several  DoD  software  technology  programs  within  ARPA  and  the 
services.  Domain  architectures  are  considered  one  of  the  key  technical  foundations  for  systematic 
reuse.  Yet  architecture  representation  to  support  reuse  remains  a  critical  technical  issue  to  over¬ 
come. 

A  number  of  DoD  software  technology  programs  are  addressing  these  difficult  architecture  repre¬ 
sentation  issues.  For  example: 

•  The  STARS  demonstration  projects  are  each  using  distinct  techniques  for  representing 
and  applying  domain  architectures  to  support  reuse,  reflecting  distinct  interpretations  of 
the  STARS  concept  of  megaprogramming. 

•  The  Air  Force  Comprehensive  Approach  to  Reusable  Defense  Software  (CARDS)  and 
Portable,  Reusable,  Integrated  Software  Modules  (PRISM)  programs  have  applied  spe¬ 
cific  architecture  representation  approaches  in  the  command  center  domain  (e.g.,  to  sup¬ 
port  the  CARDS  Command  Center  Library  and  prototype  system  composition 
capability). 

•  The  SEI  Software  Architecture  Technology  Initiative  (SATI)  is  conducting  a  number  of 
projects  exploring  the  representation  and  use  of  software  architectures,  from  both  a 
research-oriented  and  practical  perspective. 

•  The  ARPA  DSSA,  Prototech,  and  Software  Composition  programs  are  exploring  archi¬ 
tecture  representation  and  tool  support  issues  and  developing  prototype  technologies. 

1.1  Architecture  Description  Languages 

An  architecture  model  captures  part  of  the  knowledge  about  an  architecture  for  a  single  system  or 
a  family  of  systems  in  a  domain  (i.e.,  a  generic  architecture  or  domain-specific  software  architec¬ 
ture).  A  model,  by  definition,  is  incomplete  and  imperfect.  An  architecture  description  language 
(ADL)  is  a  set  of  notations,  languages,  standards  and  conventions  for  an  architecture  model.  An 
ADL  defines  a  set  of  notations  (e.g.  diagrams,  formal  languages,  natural  language  text  fields)  for 
each  view  that  the  ADL  includes.  Architecture  models  provide  one  or  more  views  of  an  architec¬ 
ture.  Views  highlight  certain  types  of  information  and  hide  other  types.  Examples  of  well-known 
architectural  views  include: 

•  data  flow  diagrams 

•  flow  charts/control  flow  diagram 

•  data  models  and  entity-relation  diagrams 

•  structure  charts 

•  computer  software  configuration  items  diagrams  (DoD-Std-2167A) 

•  module  guides  [PWC85] 

•  object-oriented  hierarchy  diagrams 

•  state  and  state  transition  diagrams 

•  process  timing  models 

•  memory  allocation  charts 

•  constraint  networks 
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Other  information  that  can  be  recorded  in  an  ADL  includes: 

•  text  descriptions  of  reusable  components, 

•  text  discussions  of  rationales  and  tradeoffs, 

•  interface  specifications  (syntactic  and  semantic) 

ADLs  are  often  supported  by  tools.  These  include: 

•  tools  for  creation,  modification,  and  browsing  of  architecture  models 

•  tools  for  refining  and  composing  systems 

•  tools  that  generate  components 

•  tools  that  analyze  and  simulate  a  system  before  it  is  built 

There  are  a  variety  of  ADLs  emerging  from  various  industrial  and  academic  research  groups.  For 
example,  UniCon  (language  for  Universal  Connector  support)  is  being  developed  at  Carnegie 
Mellon  University  to  explore  issues  of  abstractions  for  architecture  and  composition  of  systems 
[Shaw94c].  Some  ADLs  are  commercial  products  like  UNAS/SALE  (Universal  Network  Archi¬ 
tectural  Services/Software  Architects  Life-cycle  Environment)  which  was  developed  by  TRW 
and  marketed  by  Rational  [Krutchen94].  Other  ARPA  sponsored  ADLs  include  LILEANNA 
[Tracz93],  Rapide  [Luckham93],  MetaH  [Binns93],  arid  ArTek/DADSE  [Terry94].  Please  consult 
the  World  Wide  Web-based  Software  Architecture  Technology  Guide  (another  product  of  this 
task)  at  URL  http://www.stars.reston.unisysgsg.com/arCh/guide.html  for  more  information  on 
these  and  other  ADLs. 

ADLs  vary  widely  in  terms  of  what  architecture  styles  they  support  and  what  forms  of  analyses 
they  permit.  Like  other  tools,  there  is  no  one  ADL  that  best  fits  all  possible  situations. 

An  ADL  should  chosen  based  on  its  suitability  for  the  problem  domain.  For  example,  in  some 
domains,  complex  sequences  of  states  and  actions  are  common,  so  the  ADL  should  facilitate  the 
representation  of  these  applications. 

A  variety  of  groups  use  ADLs.  Each  group  has  a  different  perspective  of  what  a  good  ADL  should 
be.  People  involved  in  the  acquisition  of  software  specify  ADLs  for  procurements  and  evaluate 
architecture  models  (encoded  in  an  ADL)  that  are  included  in  proposals  and  presented  at  design 
reviews.  ADLs  are  important  tools  for  software  developers  who  design,  build,  or  re-engineer 
application  systems.  ADLs  are  even  more  important  for  domain  engineers  who  are  responsible  for 
developing  domain-specific  architectures. 

1.2  Characterizing  ADLs 

In  order  to  help  users  choose  an  appropriate  ADL,  a  descriptive  model  framework  for  ADLs 
[KC95,CK95]  is  being  developed  by  the  SEI  and  the  CARDS  program.  The  goal  is  to  answer  the 
following  questions: 

•  What  features  do  ADLs  have? 

•  What  features  help  describe  the  differences  between  ADLs? 
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The  features  are  organized  in  a  taxonomy  comprising  system-oriented,  language-oriented,  and 
process-oriented  categories.  The  framework  document  contains  a  form  for  recording  the  results  of 
analyzing  an  ADL  in  terms  of  these  features.  In  trying  to  use  the  form,  the  framework  developers 
found  it  difficult  to  objectively  analyze  an  ADL  for  some  features  without  a  context.  For  example, 
it  can  be  difficult  to  determine  the  level  of  support  an  ADL  has  for  a  certain  architecture  style 
without  trying  to  apply  the  ADL  to  that  style.  The  need  for  hands-on,  empirical  methods  to  com¬ 
plement  the  descriptive  framework  and  evaluation  form  became  evident.  One  of  the  primary 
objectives  of  STARS  task  PA12  was  to  address  this  need. 

A  key  task  goal  was  to  define  a  set  of  model  problems  for  software  architecture  and  develop  sce¬ 
narios  for  applying  ADLs  to  the  model  problems.  As  part  of  each  scenario,  the  ADL  user  is 
prompted  to  fill  in  parts  of  the  evaluation  form  based  on  how  well  the  ADL  supports  particular 
features  defined  in  the  descriptive  model  framework.  To  validate  the  scenarios,  they  were  applied 
on  two  ADLs  and  the  results  were  recorded  using  the  evaluation  form.  Section  2  of  this  document 
summarizes  the  task  activities  and  results,  including  the  approach  taken  in  developing  the  scenar¬ 
ios.  The  scenarios  are  described  in  detail  in  Sections  3  and  4.  Appendices  A  and  B  contain  the 
filled-out  evaluation  forms  resulting  from  applying  the  scenarios  to  the  two  ADLs. 
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2.0  Overview  of  Activities  and  Results 

2.1  Scenario  Development  Approach 

There  have  been  a  number  of  efforts  in  recent  years  to  develop  methods  for  evaluating  a  variety  of 
software  engineering  technologies,  including: 

•  Ada  environments  [Weiderman86] 

•  software  project  management  tools  [FS88] 

•  software  process  description  languages  [Rombach91][KR91] 

•  process  centered  frameworks  [Christie94] 

•  software  architectures  [KBAW94] 

•  maintainability  of  software  systems  [BCC95] 

These  methods  are  based  on  scenarios  that  are  rooted  in  model  problems  relevant  to  the  technolo¬ 
gies  being  evaluated.  Many  of  the  methods  were  developed  at  the  SEI  and  are  based  on  a  common 
evolving  approach  that  was  tailored  to  particular  technologies.  This  approach  is  based  on  the  fol¬ 
lowing  premises: 

•  Evaluations  should  be  based  on  the  results  of  well-defined  experiments  to  maximize 
their  objectivity  and  repeatability.  These  experiments  are  meant  to  be  performed  by  an 
unbiased  party. 

•  Methods  should  clearly  define  the  scope  of  the  functionality  to  be  evaluated  and  should 
focus  on  core  functionality  that  will  be  broadly  relevant  to  the  evaluated  technologies 
and  of  greatest  interest  to  the  evaluators. 

•  Evaluation  methods  should  be  based  on  general  user  activities  rather  than  detailed  tool 
operations. 

•  Methods  should  be  as  independent  of  the  technologies  to  be  evaluated  as  possible  to 
minimize  potential  biases. 

•  Methods  should  be  extensible  to  accommodate  additional  user  activities  and  experi¬ 
ments. 

Our  work  on  ADL  scenarios  was  heavily  influenced  by  the  methods  for  evaluating  languages 
(ADLs  are  languages),  tools  (ADLs  are  supported  by  tools),  and  process  centered  frameworks 
(ADLs  have  multiple  user  perspectives). 

There  were  several  major  issues  that  needed  to  be  resolved  in  order  to  develop  the  scenarios: 

•  How  many  scenarios  should  be  developed? 

•  Which  model  problems  should  form  the  basis  for  the  scenarios? 

•  How  much  detail  should  be  given  in  the  model  problem  description? 

•  How  can  bias  for  or  against  specific  ADLs  be  minimized? 

•  How  much  detail  should  be  given  in  the  evaluation  tasks/steps? 

•  Which  user  perspectives  should  the  scenario  cover? 

•  Which  features  in  the  descriptive  model  framework  should  be  covered  by  the  scenarios? 
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The  answer  to  the  first  question  was  based  primarily  on  the  amount  of  resources  available  for  the 
task.  It  was  important  to  develop  more  than  one  scenario  so  that  ADLs  would  be  analyzed  from 
multiple  perspectives.  Several  scenarios  would  have  been  desirable,  but  resource  limitations  dic¬ 
tated  that  we  develop  only  two. 

In  determining  which  model  problems  to  use  as  the  basis  for  each  of  the  two  scenarios,  we 
observed  that  model  problems  which  have  been  developed  to  explore  software  design  methodolo¬ 
gies  can  be  adapted  for  software  architecture  [Shaw94a].  One  of  the  more  popular  model  prob¬ 
lems,  an  automobile  cruise  control  system,  has  been  solved  as  an  academic  exercise  using  many 
different  design  methodologies,  and  the  resulting  architectures  have  been  compared  [Shaw94b]. 
We  selected  cruise  control  as  one  of  our  model  problems  because  of  this  prior  work  and  the  fact 
that  a  number  of  solution  architectures  already  exist.  For  the  other  model  problem,  we  wanted  to 
define  a  problem  in  a  DoD  application  area  that  addresses  architectures  involving  large-scale 
COTS  and  GOTS  components.  Because  of  our  familiarity  with  the  CARDS  and  PRISM  work,  we 
defined  a  problem  involving  simplified  command  center  architectures. 

The  question  of  how  much  detail  to  include  in  the  model  problem  descriptions  centers  around  the 
tradeoff  between  defining  a  model  problem  that  is  specific  enough  to  yield  reasonably  comparable 
and  repeatable  results,  yet  has  little  bias  for  or  against  any  class  of  ADLs.  Descriptions  of  model 
problems  generally  include  an  informal  set  of  requirements  for  a  system;  they  may  also  include  an 
informal  description  of  some  aspects  of  the  problem  solution  at  some  arbitrary  level  of  detail 
(e.g.,  an  informal  diagram  describing  the  general  architectural  structure  of  the  system).  We  could 
create  a  scenario  that  says,  in  summary: 

Given  a  specification  of  the  model  problem  requirements,  design  a  solution 

using  the  ADL. 

This  scenario  would  be  very  unbiased,  but  would  be  too  poorly  constrained  to  yield  very  compa¬ 
rable  results.  Note  also  that  any  scenario  requiring  lots  of  creative  activity  (e.g.,  designing  a  solu¬ 
tion  from  scratch)  could  be  quite  time  consuming,  or  at  least  the  amount  of  time  needed  could  be 
quite  unpredictable.  Another  approach  would  be: 

Given  a  specification  of  the  model  problem  and  an  informal  architecture 

description  represent  this  architecture  using  the  ADL. 

This  scenario  would  be  biased  significantly  by  the  representation  and  structure  of  the  informal 
architecture,  but  would  probably  yield  relatively  comparable  results  and  could  probably  be  per¬ 
formed  in  a  reasonably  small  and  predictable  amount  of  time.  We  chose  this  approach  and 
attempted  to  mitigate  the  representational  bias  by  designing  the  two  scenarios/model  problems  to 
impose  a  variety  of  alternative  biases  that  test  a  range  of  representation  capabilities  (e.g.,  support 
for  different  architectural  styles).  The  informal  architecture  description  includes  a  high  level  spec¬ 
ification  of  components  and  connections  along  with  a  diagram  which  shows  the  architecture  struc¬ 
ture.  More  detail  may  need  to  be  added  later  based  on  experience  in  applying  the  scenarios. 

Scenario-based  evaluation  methods  have  varying  degrees  of  detail  in  their  tasks/steps.  The  scenar¬ 
ios  that  focused  on  tool  evaluations  tend  to  have  more  detailed  steps  whereas  the  scenarios  for 
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evaluations  of  languages  tend  to  be  less  detailed  (e.g.  “represent  this”  vs.  “draw  component  1 
then...”).  ADLs  are  languages  supported  by  tools  so  the  detail  in  the  tasks/steps  tends  to  be  at  a 
higher  level  except  in  cases  where  there  is  a  need  to  probe  a  certain  tool  capability.  As  in  many  of 
the  SEI  methods,  questions  are  interspersed  with  the  tasks  to  solicit  information  about  the  pres¬ 
ence  of  absence  of  specific  features. 

Some  scenario-based  evaluation  methods  explicitly  address  multiple  user  perspectives.  For  exam¬ 
ple,  Christie’s  methods  for  evaluating  process  centered  frameworks  has  tasks  and  questions  for 
both  the  process  model  developer  and  the  end-user  [Christie94].  We  chose  to  adopt  two  user  per¬ 
spectives;  domain  engineer  and  application  engineer.  The  domain  engineer  uses  the  ADL  to  create 
the  architecture  model.  The  application  engineer  uses  the  architecture  model  recorded  in  an  ADL 
to  develop  a  system.  Both  are  roles  defined  in  STARS  reuse  processes  [STARS93]. 

The  last  issue  is  choosing  features  from  the  descriptive  model  framework  that  will  be  addressed 
by  the  scenarios.  Features  were  prioritized  in  terms  of  how  difficult  they  are  to  analyze  objectively 
outside  the  context  of  a  model  problem  and  how  practically  relevant  they  are  to  ADLs  currently 
available  for  evaluation.  Examples  of  the  ADL  features  we  have  chosen  to  emphasize  are: 

•  Support  for  various  architecture  styles 

•  Ability  to  represent  architectures  of  various  categories  of  systems  (e.g.,  real¬ 
time,  distributed) 

•  Understandability  of  architectures  described  using  the  ADL 

•  Modifiability  of  architectures  described  using  the  ADL 

•  Support  for  explicit  representation  of  variability  within  an  architecture  description  to 
facilitate  reuse 

•  Scalability  to  support  large-scale  architectures  or  components 

Each  scenario  lists  all  the  features  which  it  covers.  The  definition  and  application  of  the  scenarios 
will  lead  to  refinements  in  the  descriptive  model  framework  especially  for  features  in  the  area  of 
understandability  and  variability. 

2.2  Overview  of  Scenarios 

Two  scenarios  which  cover  many  of  the  important  features  in  the  framework  have  been  devel¬ 
oped.  One  scenario  addresses  the  automobile  cruise  control  domain  and  emphasizes  architecture 
model  creation  for  a  variety  of  different  architecture  styles  and  heterogenous  mixtures  of  styles. 
The  other  scenario  addresses  the  military  command  center  domain  and  emphasizes  architecture 
refinement,  application  building,  variability  and  modifiability  with  a  COTS-based  generic  archi¬ 
tecture.  There  is  a  certain  amount  of  unavoidable  overlap  between  the  two  scenarios,  but  a  benefit 
is  that  the  overlapping  features  are  evaluated  in  two  different  model  problem  contexts.  The  cruise 
control  and  command  center  scenarios  are  described  in  detail  in  Sections  3  and  4,  respectively. 

The  cruise  control  scenario  was  chosen  because  cruise  control  is  a  model  problem  for  which  many 
solution  architectures,  in  several  different  styles,  already  exist  [Shaw94b].  This  scenario  covers 
traditional  architecture  issues  assuming  custom  built  components.  The  scenario  includes  four 
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informal  descriptions  of  cruise  control  architectures,  each  having  a  different  architecture  style. 
The  four  styles  represented  are: 

•  main  program/subroutine 

•  pipe  and  filter 

•  object-oriented 

•  state-based/real-time 

The  four  cruise  control  systems  are  then  integrated  into  an  object-oriented  simulator  architecture 
that  is  a  heterogeneous  mix  of  styles.  The  heavy  emphasis  on  representing  a  variety  of  architec¬ 
ture  styles  may  be  premature  based  on  the  current  state  of  the  art  in  ADLs  but  we  feel  this 
approach  will  help  reveal  many  strengths  and  weaknesses  in  ADLs. 

The  command  and  control  scenario  is  meant  to  address  issues  of  “megaprogramming”  (central  to 
the  DoD  Reuse  Vision  and  Strategy)  wherein  architectures  must  support  the  use  (and  reuse)  of 
large-scale  COTS  and  GOTS  components.  One  issue  is  the  ability  to  handle  variability,  refine¬ 
ment  and  application  building  (i.e.,  system  composition)  in  a  generic  architecture  for  a  domain  or 
product  line.  The  second  issue  is  connecting  large  pre-existing  components  that  were  not  origi¬ 
nally  designed  to  fit  together.  We  have  chosen  two  architecture  styles  that  are  popular  approaches 
to  the  connection  problem;  communicating  processes  and  event  systems.  The  first  informal  archi¬ 
tecture  description  specifies  remote  procedure  calls  (RPCs)  as  defined  in  OSF’s  Distributed  Com¬ 
puting  Environment  standard  [OSF93]  [Shirley93].  The  second  informal  architecture  description 
specifies  the  Common  Object  Request  Broker  Architecture  (CORBA)  standard  [OMG91].  The 
important  differences  are  that  the  communicating  processes  architecture  has  synchronous  point  to 
point  connections  whereas  the  event  system  architecture  has  asynchronous  broadcast  connections. 
This  scenario  may  also  be  somewhat  ambitious  for  currently  available  ADLs  but  it  provides  a 
goal  for  ADL  researchers. 

2.3  Applying  the  Scenarios 

To  validate  the  scenarios  and  produce  concrete  examples  of  ADL  evaluations  using  the  scenarios, 
a  key  aspect  of  the  task  was  to  apply  the  scenarios  in  a  hands-on  manner  to  a  small  number  of 
ADLs  (and  their  supporting  tools)  and  record  the  results.  Several  toolsets  supporting  ADLs  were 
solicited  from  their  suppliers  for  installation  and  use  at  a  STARS  facility.  Since  many  ADL  sup¬ 
port  tools  are  currently  research  prototypes,  the  suppliers  were  typically  the  tool  developers  in 
research  organizations,  but  some  commercial  vendors  were  also  contacted.  Some  of  the  tools 
could  not  be  obtained  in  time  to  perform  an  evaluation,  while  others  included  components  requir¬ 
ing  license  fees  that  were  not  budgeted  in  the  task.  In  the  end,  we  selected  two  ADLs/toolsets  for 
analysis: 


•  Capture,  from  CTA,  Inc. 

•  UniCon,  from  the  Carnegie  Mellon  University’s  Composable  Systems  Group. 

Capture  is  designed  to  support  legacy  system  management  and  domain  analysis.  It  enables  the 
architectures/designs  of  families  of  systems  and  subsystems  to  be  described  using  a  variety  of 
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different  notations.  The  descriptions  within  a  family  can  be  readily  compared,  contrasted,  and 
evaluated  for  reuse  or  to  support  design  decisions  in  system  development  and  maintenance 
efforts.  Capture  will  soon  be  offered  as  a  commercial  product,  by  CTA. 

UniCon  (language  for  Universal  Connector  support)  is  a  prototype  language  and  toolset  that  has 
been  developed  at  CMU  to  explore  research  issues  involving  the  formal  representation  of  a  core 
set  of  software  architecture  constructs  and  architecture  styles.  UniCon  treats  both  the  software 
components  of  an  architecture  and  their  interconnections  as  first-class  architecture  constructs.  The 
toolset  enables  both  textual  and  graphical  architecture  descriptions,  both  of  which  were  used  dur¬ 
ing  our  analysis. 

The  evaluation  forms  describing  the  results  of  applying  the  scenarios  to  these  ADLs  are  included 
in  Appendices  A  and  B.  The  forms  themselves  provide  significant  information  about  the  features 
that  are  defined  as  part  of  the  SEI/CARDS  descriptive  model  framework,  but  some  readers  may 
need  additional  information  about  the  framework  in  order  to  adequately  interpret  the  results.  The 
best  source  of  this  information  is  the  draft  technical  report  describing  the  framework  [KC95].  It 
has  not  yet  been  formally  published,  but  is  available  in  postscript  form  via  the  World  Wide  Web 
Software  Architecture  Technology  Guide  (http://www.stars.reston.unisysgsg.com/arch/guide.html) 
and  may  be  obtained  in  hard  copy  form  from  Paul  Clements  of  the  SEI  to  a  limited  degree. 

DISCLAIMER:  It  is  important  to  note  that  the  information  recorded  in  the  forms  has  not  been 
reviewed  with  the  ADL/tool  suppliers.  The  forms  may  reflect  misinterpretations  or  incorrect 
assumptions  on  our  part  that  we  have  not  had  an  opportunity  to  identify  or  correct.  The  primary 
function  of  the  forms  in  this  document  is  to  provide  examples  of  how  the  scenarios  can  be  used  in 
conjunction  with  the  SEI/CARDS  framework  to  analyze  ADLs.  Although  we  believe  the  forms 
contain  useful  information  about  the  specific  ADLs  we  have  analyzed,  the  data  should  not  be 
treated  as  definitive  and  should  be  corroborated  before  being  used  as  the  basis  for  ADL-related 
decisions. 
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3.0  Cruise  Control  Scenario 

3.1  Scenario  Objectives 

The  automobile  cruise  control  scenario  emphasizes  architecture  model  creation  and  the  interpreta¬ 
tion  of  the  resulting  model.  The  cruise  control  model  problem  represents  a  more  traditional  single 
system  development  approach,  in  contrast  to  the  domain-specific  product-line  oriented  develop¬ 
ment  approach  that  is  found  in  the  command  and  control  scenario.  The  scenario  helps  determine 
the  applicability  of  the  ADL  for  a  variety  of  different  architecture  styles  (including  a  heteroge¬ 
nous  mixtures  of  styles)  and  system  categories.  The  scenario  probes  the  fundamental  language 
characteristics  of  the  ADL  including  how  the  language  captures  and  communicates  information 
and  what  the  ADL  assumes  about  intended  users.  Process  guidance  and  tool  support  for  an  ADL 
are  also  covered.  The  scenario  has  a  special  focus  on  validation  of  the  architecture  model  that  was 
created.  In  the  later  stages  of  the  scenario  there  is  a  special  step  that  analyzes  an  ADL’s  capability 
to  compose  large  pieces  of  the  architecture  into  another  architecture.  The  specific  ADL  feature 
evaluation  objectives  of  the  cruise  control  scenario  are  found  in  section  3.4.  Questions  about  the 
usability  of  the  ADL  are  added  to  augment  the  features  from  the  descriptive  model  framework. 

3.2  Problem  Domain  Description 

There  are  several  different  car  manufacturers  who  (hypothetically)  each  designed  their  digital 
cruise  control  system  based  on  the  version  of  the  cruise  control  problem  described  by  Booch 
[Booch86]. 

•  The  GM  cruise  control  architecture  has  a  main  program/subroutine  style. 

•  The  Ford  cruise  control  architecture  has  a  pipe  &  filter  style. 

•  The  Chrysler  cruise  control  architecture  has  an  object-oriented  style. 

•  The  Toyota  cruise  control  architecture  has  a  state-based/real-time  style. 

The  Department  of  Transportation  wants  to  build  an  object-oriented  intelligent  vehicle  highway 
system  (IVHS)  simulator  that  will  allow  experimentation  with  different  planning  and  control 
algorithms.  IVHS  keeps  traffic  moving  and  avoids  accidents  on  a  superhighway.  The  IVHS  must 
incorporate  each  of  the  digital  cruise  control  architectures  so  that  it  can  simulate  control  signals  to 
the  cruise  control  systems  in  a  car  and  predict  the  effects  of  these  signals  while  planning. 

3.3  Informal  Architecture  Description 

The  purpose  of  this  description  is  to  specify  basic  components  and  data  flow  so  that  the  architec¬ 
tures  described  in  various  ADLs  will  be  comparable  and  not  need  to  be  designed  from  scratch  for 
each  ADL.  The  various  designs  below  are  compared  in  [Shaw94b].  The  basic  characteristics  of 
architecture  styles  are  described  in  [GS93]. 

The  informal  architecture  descriptions  are  meant  to  be  ADL-independent  so  they  must  maintain  a 
fine  balance  between  being  informative  and  holding  a  bias  for  or  against  specific  ADL  character¬ 
istics.  Therefore  the  description  includes: 
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•  An  architecture  style  description  that  implies  semantics  for  the  component  and  connec¬ 
tion  types 

•  A  list  of  components,  their  component  types,  and  a  brief  description 

•  A  diagram  that  shows  how  components  are  connected.  If  no  connection  is  shown,  it 
should  be  assumed  that  no  connection  exists.  The  diagram  may  include  a  key  to  assist  in 
interpreting  the  diagram  and  to  identify  connections  that  do  not  conform  to  the  architec¬ 
ture  style  (if  any). 

3.3.1  GM  Architecture 

The  GM  architecture  (main  program/subroutine  style)  uses  Booch’s  functional  design  [Booch86]. 

This  style  is  based  on  the  common  subroutine  calling  that  is  found  in  most  traditional  program¬ 
ming  languages.  The  main  program  calls  the  subroutines  in  some  specified  sequence  [GS93]. 

Components  are: 

•  Cruise_Control_System  (main):  continuously  calls  each  subroutine  below  in  the  order 
shown. 

•  Get_Desired_Speed  (subroutine):  from  driver 

•  Get_Current_Speed  (subroutine):  from  wheel  sensor 

•  Get_Brake_State  (subroutine):  on/off 

•  Calculate_Throttle_Setting  (subroutine):  calculates  value  for  engine  throttle  setting. 

•  Put_Throttle_Value  (subroutine):  adjusts  the  throttle  setting. 
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Figure  1:  GM  Architecture 
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3.3.2  Ford  Architecture 

The  Ford  architecture  (pipe  &  filter  style)  is  Booch’s  data  flow  diagram  [Booch86]  transformed 
into  a  pipe  &  filter  architecture.  UNIX  pipe  &  filter  model  abstractions  should  be  assumed.  In  fil¬ 
ters  output  begins  before  the  input  is  consumed.  Filters  do  not  share  state  with  other  filters 
[GS93].  Components  are: 

•  Calculate_Current_Speed  (filter):  continuously  outputs  current  speed 

•  Calculate_Desired_Speed  (filter):  continuously  outputs  desired  speed 

•  Set_Brake_State  (filter):  continuously  outputs  brake  state 

•  Calculate_Throttle_Setting  (filter):  continuously  outputs  setting  to  throttle 


Figure  2:  Ford  Architecture 
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3.3.3  Chrysler  Architecture 

The  Chrysler  architecture  (00  style)  uses  Booch’s  00  design  [Booch86].  Each  object  in  a  class  is 
an  abstract  data  type  (ADT)  that  has  a  well  defined  interface  and  preserves  an  internal  state 
[GS93].  The  object  is  an  abstraction  of  a  real  world  entity  or  some  internal  computing  entity.  The 
object  is  accessed  only  through  its  operations.  Classes  inherit  data  definitions  and  operations  from 
parent  classes. 

•  Driver  (class)  (parent  class  Agent):  operations  provide  driver  commands 

•  Brake  (class)  (parent  class  Device):  operations  provide  brake  state 

•  Clock  (class)  (parent  class  Device):  operations  provide  timing  signals 

•  Wheel  (class)  (parent  class  Device):  operations  provide  rotation  data 

•  Engine  (class)  (parent  class  Device):  operations  provide  engine  state 

•  Accelerator  (class)  (parent  class  Device):  operations  provide  accelerator  value 

•  Throttle  (class)  (parent  class  Device):  operations  control  throttle 

•  Current_Speed  (class)  (parent  class  Speed):  stores  and  updates  speed  of  vehicle 

•  Desired_Speed  (class)  (parent  class  Speed):  stores  and  updates  desired  speed 
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Figure  3:  Chrysler  Architecture 
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3.3.4  Toyota  Architecture 

The  Toyota  architecture  (state-based/real-time  style)  uses  Smith  &  Gerhart’s  activities  and  states 
[SG88].  The  functional  decomposition,  which  partitions  functionality  into  activities,  is  influenced 
by  the  emphasis  on  states  and  state  transitions.  This  scenario  only  includes  the  control  speed  part 
of  the  design  and  not  the  extra  monitoring  functions  in  [SG88].  Components  are: 

•  Select_Speed  (activity):  stores  current  speed 

•  Clear_Speed  (activity):  clears  speed  setting 

•  Desired_Speed  (data  store):  desired  speed  value 

•  Maintain_Speed  (activity):  maintains  speed 

•  Increase_Speed  (activity):  increases  speed 

•  Check_Speed  (activity):  check  if  a  previously  set  speed  has  been  reached 

•  Speed_Control  (control  activity):  senses  state  and  issues  commands  to  other  activities 

•  Test_Pedal_Deflection  (activity):  test  deflection  of  acceleration  pedal 

States  for  Speed_Control  are: 

•  Initial  (state):  state  immediately  after  driver  turns  cruise  control  on  (no  previous  speed 
setting) 

•  Accelerate_New_Speed  (state):  driver  is' pushing  accelerator  button  (not  gas  pedal) 

•  Resume_Cruise  (state):  resume  last  previous  cruising  speed 

•  Cruise_Activated  (state):  cruising  speed  is  being  maintained 

•  Cruise_Inactivated  (state):  cruise  disengaged  (previous  cruising  speed  not  cleared) 

•  Error  (state):  cruise  control  not  responding 
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Figure  4:  Toyota  Architecture 
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3.3.5  IVHS  Simulator  Architecture 

The  IVHS  simulator  design  was  invented  for  this  scenario.  The  first  four  components  are  the 
cruise  control  systems  described  above.  The  top-level  architecture  style  is  object-oriented  but  the 
overall  style  is  heterogeneous  because  the  system  consists  of  components  with  different  styles. 

•  GM  cruise  control  (class)  (parent  class  Cruise_Control) 

•  Ford  cruise  control  (class)  (parent  class  Cruise_Control) 

•  Chrysler  cruise  control  (class)  (parent  class  Cruise_Control) 

•  Toyota  cruise  control  (class)  (parent  class  Cruise_Control) 

•  Traffic  controller  (class)  -  Avoids  collisions.  Maintains  distance  between  vehicles  by 
controlling  their  speed.  Allows  addition  and  removal  of  vehicles  from  the  simulation. 
Reports  the  current  state  of  traffic  and  records  traffic  patterns. 

•  Traffic  planner  (class)  -  Plans  the  steps  taken  by  the  controller  and  checks  their  safety. 


Figure  6:  IVHS  Simulator  Architecture 
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3.4  Tasks  and  Evaluation  Questions 

The  following  tasks  are  divided  between  two  main  types  of  users;  domain  engineers  and  applica¬ 
tion  engineers.  Most  questions  refer  to  the  numbered  features  in  the  ADL  descriptive  model 
framework  (all  numbers  in  parentheses  refer  to  features  in  [KC95]). 

3.4.1  Domain  Engineer 

The  domain  engineer  creates  the  architecture  model. 

3.4.1.1  Create  Architecture  Models  for  Cruise  Control  Systems 

Use  the  ADL  to  describe  the  architecture  for  as  many  of  the  four  cruise  control  architectures/ 
styles  as  possible  (i.e.,  either  the  ADL  was  explicitly  designed  to  support  this  style  or  the  ADL 
can  support  this  style  but  provides  few  or  no  built-in  features  to  do  so).  Use  all  process  support 
materials  available  including  process  definitions,  user  manuals,  and  training  course  materials.  Use 
multiple  views,  if  they  are  available  and  applicable. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form.  Each 
column  in  the  following  tables  indicates  a  level  in  the  feature  hierarchy. 


Process  Support 
(3.3.7) 

process  definition 

users  manual 

training  course 

Process-oriented 

(3.3) 

architecture  cre¬ 
ation  support  (3.3.1) 

textual  editor 

graphical  editor 

System-oriented 

(3.1) 

applicability  (3.1.1) 

architecture  style 
(3.1.1.1) 

main  program  and 
subroutines 

pipes  and  filters 

object-oriented 

state-based/real- 

time 
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views  (3.2.4) 

multiple  views 
(3.2.4.1) 

syntactic  views 
(3.2.4.2) 

semantic  views 
(3.2.4.3) 

inter-view  cross  ref¬ 
erence  (3.2.4.4) 

Language-oriented 

(3.2) 

language  definition 
quality  (3.2.1) 

formality  (3.2. 1.1) 

completeness 

(3.2.1.2) 

consistency  (3.2.1.3) 

Expressive  power 
(3.2.2) 

primitives  (3.2.2.1) 

extensibility 

(3.2.2.2) 

abstractions 
(3.2.2.3  -  see  table 
after  3.2.8) 

Evaluate  the  following  usability  features  of  the  ADL  (not  in  the  current  framework)  on  a  scale 
from  1  to  5  (1  =  Disagree  ..  5  =  Agree)  [Christie94]  [FS88]: 

•  The  ADL  was  easy  to  learn. 

•  The  ADL  tools  streamlines  the  process  of  creating  an  architecture  description. 

•  The  ADL  is  clear  and  consistent  in  its  use  of  terminology. 

•  The  ADL  tools  have  a  consistent  “look  and  feel”  in  their  user  interface. 
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•  The  ADL  tools  display  available  options  based  on  the  current  state. 

•  The  ADL  tools  provide  on-line  help. 

•  The  ADL  tools  provide  useful  error  messages. 

3.4.1.2  Architecture  Validation 

Do  completeness  and  consistency  checks  on  described  architectures. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form: 

architecture  valida-  syntax  checker 

tion  support  (3.3.2) 

semantics  checker 

completeness 

checker 

internal  consistency 
checker 

3.4.1.3  Create  Architecture  Models  for  IVHS  Simulator 

Use  the  ADL  to  describe  the  IVHS  simulator  architecture. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form: 

System-oriented  applicability  (3.1.1)  architecture  style  heterogeneous  styles 
(3.1)  (3.1.1.1) 

Modifiability  (3.2.7)  scalability  (3.2.7.2)  abstraction  levels 

cross  referencing 
composition 
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3.4.2  Application  Engineer 

The  application  engineer  is  the  end  user  of  the  architecture  model.  The  steps  below  should  be  per¬ 
formed  by  someone  who  didn’t  do  the  steps  in  3.4.1. 

3.4.2.1  Interpret  Architectures  Model 

Answer  questions  about  the  architecture  from  information  in  the  ADL.  This  is  an  experiment  to 
determine  how  the  ADL  communicates  information. 

•  What  are  the  inputs  of  Get_Desired_Speed  in  the  GM  architecture? 

•  What  are  the  outputs  of  Set_Brake_State  in  the  Ford  architecture? 

•  What  is  the  parent  class  of  Wheel  in  the  Chrysler  architecture? 

•  What  causes  a  transition  to  the  Resume_Cruise  in  the  Toyota  architecture? 


Complete  the  following  parts  of  the  ADL  descriptive  model  evaluation  form: 


architecture  refine¬ 
ment  support  (3.3.3) 

browser 

bih 

search  tool 

3.4.2.2  Evaluation  of  ADL 

Evaluate  the  following  usability  features  of  the  ADL  (not  in  the  current  framework)  on  a  scale 
from  1  to  5  (1  =  Disagree  ..  5  =  Agree)  [Christie94]  [FS88]: 

•  The  ADL  screen  layouts  were  easy  to  understand. 

•  The  ADL  was  easy  to  learn. 

•  The  icons  for  components  were  clearly  distinguishable  and  easy  to  read. 

•  The  icons  for  connections  were  clearly  distinguishable  and  easy  to  read. 

•  The  ADL  makes  effective  use  of  color. 

•  The  ADL  is  clear  and  consistent  in  its  use  of  terminology. 

•  The  ADL  tools  have  a  consistent  “look  and  feel”  in  their  user  interface. 

•  The  ADL  tools  display  available  options  based  on  the  current  state. 

•  The  ADL  tools  provide  on-line  help. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form: 


readability  (3.2.5) 

embedded  com¬ 
ments  (3.2.5. 1) 

presentation  con¬ 
trol  (3.2.5.2) 
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Characteristics  of 
intended  users 
(3.2.6) 

Target  users 
(3.2.6.1) 

Expertise  (3.2.6.2) 

System-oriented 

(3.1) 

applicability  (3.1.1) 

system  category 
(3.1.1.2) 

hard  real-time 

soft  real-time 

embedded 
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4.0  Command  and  Control  Scenario 

4.1  Scenario  Objectives 

The  command  and  control  (C2)  scenario  is  meant  to  address  key  issues  of  megaprogramming 
involving  the  use  and  reuse  of  large-scale  components.  The  C2  scenario  has  more  focus  on  appli¬ 
cation  engineering  aspects  than  the  cruise  control  scenario  but  model  creation  is  still  a  major  task. 
One  major  issue  for  the  scenario  is  the  ability  to  handle  variability,  refinement,  and  application 
building  (i.e.,  system  composition)  in  a  generic  architecture  for  a  domain  or  product  line.  The  C2 
architecture  includes  a  generic  component  structure  as  well  as  instances  of  components  that  can 
be  plugged  into  the  structure.  The  scenario  also  addresses  the  issue  of  connecting  large  pre-exist¬ 
ing  components  that  were  not  originally  designed  to  fit  together,  such  as  commercial-off-the-shelf 
(COTS)  products  and  large  components  from  existing  government  developed  systems  (i.e.,  gov¬ 
ernment-off-the-shelf  (GOTS)  components).  This  constraint  leads  to  architecture  styles  which  can 
accommodate  these  large  components.  The  scenario  also  has  a  special  focus  on  modifying  an 
architecture  model  from  one  style  to  another.  The  specific  ADL  feature  evaluation  objectives  of 
the  command  and  control  scenario  are  found  in  section  4.4.  Questions  about  the  usability  of  the 
ADL  are  added  to  augment  the  features  from  the  descriptive  model  framework. 

4.2  Problem  Domain  Description 

The  DoD  wants  to  develop  military  command  centers  based  on  large  COTS  and  GOTS  compo¬ 
nents.  The  DoD  domain  engineering  team  needs  to  use  an  ADL  to  develop  a  simple  generic  archi¬ 
tecture  from  which  the  DoD  application  engineering  team  can  quickly  build  command  centers. 
The  domain  engineering  team  first  creates  an  architecture  with  a  communicating  processes  style 
and  later  revises  it  to  have  an  event  system  style. 

4.3  Informal  Architecture  Description 

The  simple  generic  architecture  for  command  and  control  systems  is  based  on  a  subset  of  the 
PRISM  generic  command  center  architecture  [PRISM93].  Some  of  the  component  descriptions 
are  based  on  the  CARDS  Command  Center  Library  [CARDS94]. 

The  informal  architecture  descriptions  are  meant  to  be  ADL-independent  so  they  must  maintain  a 
fine  balance  between  being  informative  and  holding  a  bias  for  or  against  specific  ADL  character¬ 
istics.  Therefore  the  description  includes: 

•  An  architecture  style  description  that  implies  semantics  for  the  component  and  connec¬ 
tion  types 

•  A  list  of  components,  their  component  types,  and  a  brief  description 

•  A  diagram  that  shows  how  components  are  connected.  If  no  connection  is  shown,  it 
should  be  assumed  that  no  connection  exists.  The  diagram  may  include  a  key  to  assist  in 
interpreting  the  diagram  and  to  identify  connections  that  do  not  conform  to  the  architec¬ 
ture  style  (if  any). 

The  C2  architecture  contains  the  following  components: 
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•  Geographical  Information  System  (GIS)  GOTS  or  COTS:  A  Geographic  Information 
System  (GIS)  is  used  for  presenting  and  manipulating  information  in  a  geographical 
context.  In  basic  terms,  a  GIS  links  tabular  data  as  found  in  a  traditional  database  with 
the  visual  world  of  maps  and  charts.  GISs  come  in  basically  two  flavors:  vector  and  ras¬ 
ter.  A  GIS  should  provide  the  ability  to  add  well-defined  standard  symbols  to  2-  and  3- 
dimensional  maps,  and  provide  tools  to  perform  analysis  on  both  the  maps  and  added 
symbols.  Typical  analysis  requires  polygon  overlay,  network  routing,  zoom  in/out. 
Communicating  with  a  database  is  necessary  to  add  dynamic  and  static  data  to  the  view 
of  the  map. 

•  DBMS  COTS:  The  Database  Management  System  (DBMS)  stores  and  manages  tables 
of  data  that  the  Command  Center  will  query  and  modify  during  daily  activities.  The 
DBMS  should  support  a  relational  data  model  and  a  client/server  architecture. 

•  DataBase  Broker  COTS:  The  database  broker  serves  as  an  interface  between  the  DBMS 
and  other  applications  requesting  the  DBMS  services.  Its  purpose  is  to  provide  better 
modularization  and  reusability  for  the  DBMS.  The  database  broker  receives  requests  for 
database  services  in  “generic”  or  standard  SQL.  The  request  is  translated  into  com¬ 
mands  and  functions  recognized  by  a  particular  DBMS  (such  as  Sybase  or  Oracle).  The 
database  broker  allows  other  DBMSs  to  be  “plugged”  in  or  out  without  affecting  the  cli¬ 
ent  applications  that  rely  upon  the  database  services  provided  by  the  DBMS. 

•  Message  Processor  GOTS  or  COTS:  The  message  processor  (MP)  component  validates 
the  accuracy  of  incoming  fixed-format  messages  against  a  set  of  predefined  message 
templates.  Those  incoming  messages  that  pass  validation  are  then  translated  into  SQL 
formatted  entries  that  are  passed  on  to  the  database  broker  and  then  the  DBMS  for  entry 
into  the  database  tables.  Those  messages  that  are  determined  as  invalid  are  stored  in  a 
file,  and  the  operator  is  notified  of  invalid  message  receipt.  The  MP  provides  automatic 
parsing,  routing,  and  storing  of  selected  incoming  messages,  both  free-text  and  fixed- 
format.  The  MP  also  supports  the  generation  of  outgoing  messages. 

•  Desktop  Publisher  COTS  (optional  component):  Desktop  publishing  components  are 
similar  to  word  processors  but  with  advanced  features.  Some  of  these  advanced  features 
include:  the  capability  to  create/edit  graphic  figures  and  images  within  the  system,  and 
functionality  for  specifying  the  layout  of  the  document. 

•  Event  Manager  (component  in  event  systems  architecture  model  -  see  figure  2):  This 
component  provides  inter-component  communication.  The  event  manager  is  sometimes 
called  middleware  or  an  object  request  broker.  It  addresses  the  requirement  to  provide 
communications  between  software  components  in  a  way  that  is  compatible  with  POSIX 
and  GOSIP  standards.  This  component  ensures  the  delivery  of  messages  and  data,  pro¬ 
vides  message  transfer  structure,  and  may  include  some  performance  monitoring 

•  User  Interface  (custom  component):  This  component  is  a  graphical  user  interface  for  the 
generic  command  center. 
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The  following  is  a  list  of  component  instances  (actual  components  that  can  be  plugged  in  to  per¬ 
form  the  functions  defined  by  the  abstract  components  in  the  architecture  descriptions); 

GIS: 

•  OILSTOCK  (GOTS) 

•  Delorme  (COTS) 

DBMS: 

•  Oracle  (COTS) 

•  Sybase  (COTS) 

•  Informix  Online  (COTS) 

Database  Broker: 

•  Omni  SQL  Gateway  (COTS  -  Sybase) 

Message  Processor: 

•  TOPIC  (COTS) 

•  JMAPS  (GOTS) 

Desktop  Publisher: 

•  FrameMaker  (COTS) 

•  Interleaf  (COTS) 

Event  Manager: 

•  CORBA(COTS) 

User  Interface  (custom  built): 

•  MOTIF  version 

•  MS  Windows  version 

4.3.1  Communicating  Processes  Architecture 

In  the  communicating  processes  architecture  depicted  in  Figure  1  (see  [GS93]),  components  com¬ 
municate  directly  to  other  components  in  a  synchronous  manner  through  remote  procedure  calls 
(RPCs);  therefore  there  is  no  event  manager  component.  The  RPC  mechanism  is  compliant  with 
OSF’s  Distributed  Computing  Environment  (DCE). 

The  Desktop  Publishing  component  is  optional  in  that  not  all  command  centers  built  from  this 
architecture  will  include  this  component. 

4.3.2  Event  Systems  Architecture 

The  event  systems  architecture  depicted  in  Figure  2  uses  an  asynchronous  event  broadcast  form  of 
communication  between  components  [GS93].  Most  of  the  components  communicate  through  an 
event  manager  component.  The  interfaces  to  the  DBMS  and  user  interface  component  are  still  via 
RPC.  The  event  manager  is  a  CORBA-compliant  Object  Request  Broker  [OMG].  The  compo¬ 
nents  use  the  CORBA  dynamic  invocation  interface. 
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4.4  Tasks  and  Evaluation  Questions 

4.4.1  Domain  Engineer 

The  domain  engineer  creates  the  architecture  model. 

4.4.1.1  Create  Architecture  Model  for  Command  and  Control  System 

Use  the  ADL  to  describe  the  communicating  processes  architecture  shown  in  Figure  1  and  all 
component  instances  listed  in  section  4.3.  The  ADL  may  be  explicitly  designed  to  support  this 
style  or  the  ADL  can  support  this  style  but  provides  few  or  no  built-in  features  to  do  so.  Use  all 
process  support  materials  available  including  process  definitions,  users  manuals,  and  training 
course  materials.  Use  multiple  views,  if  they  are  applicable  in  a  particular  ADL. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form.  Each 
column  in  the  following  tables  indicates  a  level  in  the  feature  hierarchy. 


Process-oriented 

(3.3) 

architecture  cre¬ 
ation  support  (3.3.1) 

textual  editor 

graphical  editor 

Process  Support 
(3.3.7) 

process  definition 

users  manual 

training  course 

System-oriented 

(3.1) 

applicability  (3.1.1) 

architecture  style 
(3.1.1.1) 

communicating  pro¬ 
cesses 

event  systems 
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Language-oriented  language  definition  completeness 

(3.2)  quality  (3.2.1)  (3.2.1.2) 

consistency  (3.2.1.3) 

Expressive  power  primitives  (3.2.2.1) 

(3.2.2) 

extensibility 

(3.2.2.2) 

abstractions 
(3.2.2.3  -  see  table 
after  3.2.8) 

views  (3.2.4)  multiple  views 

(3.2.4.1) 

syntactic  views 

(3.2.4.2) 

semantic  views 

(3.2.4.3) 

inter-view  cross  ref¬ 
erence  (3.2.4.4) 


scalability  (3.2.7.2)  component  size 
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Evaluate  the  following  usability  features  of  the  ADL  (not  in  the  current  framework)  on  a  scale 
from  1  to  5  (1  =  Disagree  ..  5  =  Agree)  [Christie94]  [FS88]: 

•  The  ADL  was  easy  to  learn. 

•  The  ADL  tools  streamlines  the  process  of  creating  an  architecture  description. 

•  The  ADL  is  clear  and  consistent  in  its  use  of  terminology. 

•  The  ADL  tools  have  a  consistent  “look  and  feel”  in  their  user  interface. 

•  The  ADL  tools  display  available  options  based  on  the  current  state. 

•  The  ADL  tools  provide  on-line  help. 

•  The  ADL  tools  provide  useful  error  messages. 

4.4.1.2  Modify  Architecture  Model 

Modify  the  communicating  processes  architecture  model  that  was  created  in  step  4.4. 1 . 1  so  that  it 
now  describes  the  event  systems  architecture  in  Figure  2. 

Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form. 


modifiability  (3.2.7) 

ease  of  change 

(3.2.7.1) 

4.4.2  Application  Engineer 

The  application  engineer  is  the  end  user  of  the  architecture  description.  These  steps  should  be  per¬ 
formed  by  someone  who  didn’t  do  the  steps  in  4.4.1. 

4.4.2. 1  Component  Qualification 

Component  qualification  is  the  process  of  determining  how  well  a  new  component  “fits”  into  the 
architecture.  By  using  only  the  information  in  the  ADL,  develop  a  list  of  criteria  for  qualifying  a 
new  GIS  component. 


Complete  the  following  parts  of  the  ADL  descriptive  model  evaluation  form: 


architecture  refine¬ 
ment  support  (3.3.3) 

browser 

search  tool 
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readability  (3.2.5) 

embedded  com¬ 
ments  (3.2.5. 1) 

presentation  con¬ 
trol  (3.2.5.2) 

Characteristics  of 
intended  users 
(3.2.6) 

Target  users 
(3.2.6.1) 

Expertise  (3.2.6.2) 

system  category 
(3.1.1.2) 

COTS  and  GOTS 

distributed 

Answer  questions  about  the  ADL  from  the  application  engineer  perspective. 

Evaluate  the  following  usability  features  of  the  ADL  (not  in  the  current  framework)  on  a  scale 
from  1  to  5  (1  =  Disagree  ..  5  =  Agree)  [Christie94]  [FS88]: 

•  The  ADL  screen  layouts  were  easy  to  understand. 

•  The  ADL  was  easy  to  learn. 

•  The  icons  for  components  were  clearly  distinguishable  and  easy  to  read. 

•  The  icons  for  connections  were  clearly  distinguishable  and  easy  to  read. 

•  The  ADL  makes  effective  use  of  color. 

•  The  ADL  is  clear  and  consistent  in  its  use  of  terminology. 

•  The  ADL  tools  have  a  consistent  “look  and  feel”  in  their  user  interface. 

•  The  ADL  tools  display  available  options  based  on  the  current  state. 

•  The  ADL  tools  provide  on-line  help. 

4.4.2.2  Application  Building 

Build  an  application  system  by  refining  the  event  system  architecture  using  any  tools  available  for 
the  ADL.  The  optional  desktop  publisher  component  will  be  included  in  the  application.  Choose 
instances  for  each  component  to  plug  into  the  architecture.  The  result  will  be  a  detailed  design 
derived  from  the  architecture. 
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Complete  the  following  parts  of  the  ADL  descriptive  model  framework  evaluation  form: 


architecture  refine¬ 
ment  support  (3.3.3) 

incremental  refine¬ 
ment 

application  build¬ 
ing  (3.3.5) 
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(N  V)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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Notes:  (CC)  =  results  based  on  Cruise  Control  Scenario,  (C2)  =  results  based  on  Command  &  Control  Scenario,  otherwise  results  are  composite. 
(N  V)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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(NV)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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3.3  Process-orient©d  Support:  Unless  otherwise  indicated,  answer  as  follows: 
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Y  =  Not  supported  by  any  tool,  but  ADL  contains  enough  information  to  perform  the  analysis 
N  =  Not  supported  by  information  in  the  language. 

E  =  supported  by  a  tool  external  to  the  ADL. 
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Notes:  (CC)  =  results  based  on  Cruise  Control  Scenario,  (C2)  =  results  based  on  Command  &  Control  Scenario,  otherwise  results  are  composite. 
(NV)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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Notes:  (CC)  =  results  based  on  Cruise  Control  Scenario,  (C2)  =  results  based  on  Command  &  Control  Scenario,  otherwise  results  are  composite. 
(NV)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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Notes:  (CC)  =  results  based  on  Cruise  Control  Scenario,  (C2)  =  results  based  on  Command  &  Control  Scenario,  otherwise  results  are  composite. 
(NV)  =  not  verified,  based  on  information  supplied  by  vendor/creator. 
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